In a recent webinar (you can access the on demand recording here), mike.malcangio and I discussed the barriers to service catalog success, and good practices, before looking at how service catalog technology is evolving. This blog covers some of the common barriers to success — how many do you recognize?
You can download the deck here.
But first a little history …
The IT service catalog, service request catalog, or self-service portal continues to be a focus for corporate IT organizations of all sizes.
Done right, a fit-for-purpose service catalog (I'll use this, as the most-commonly used term, from now on) can play a big part in realizing efficiencies, improving IT's service experience, and raising the corporate perception of the IT organization's worth. The service catalog can also be a key building block in extending IT service management (ITSM) best practices, processes, and technology to other business service functions to achieve a consistent, enterprise approach to service delivery and service experience — you might call it "enterprise service management."
But many organizations still struggle to fully deliver on the service catalog's promise. As with the CMDB before it, the service catalog needs to be treated as so much more than the introduction of new ITSM technology.
The service catalog obsession
IMO the service catalog has too often been recommended or sold, and potentially bought, as the cure to the majority — if not all — of the enterprise IT organization's ITSM, IT service delivery, and customer perception ills. In some ways it has felt like that it didn't matter what the question was, the answer always seemed to be: "Buy a service catalog."
But also that there was the danger that organizations would focus on the service catalog tool, over the required supporting envelope of people and processes, such that the service catalog tool could end up as "CMDB 2.0" — a place where IT service data goes to die after an expensive IT implementation project. But, thankfully, I think we've collectively learnt a lot in the last 5 years … but the issue is whether these lessons have been effectively disseminated to real-world ITSM (or IT) professionals enough.
Lessons that have been translated into good or best practices …
Firstly, are we all talking about the same service catalog?
For me one of the biggest barriers is how people think of "service catalog" and use the term. It means many things to many people. Is it a list of available services, a self-service capability, or a more complex employee portal?
And I've used this diagram before to talk to the fact that we tend focus on the middle circle — this thing called service catalog (usually a tool) — but expect to accomplish the whole.
So is it any wonder that so many service catalog initiatives are considered sub-optimal if we charge at the middle circle and neglect to fully consider the outer two? My next diagram adds to this (and again I have used it before) …
Many talk of "an Amazon.com-like" experience, or storefront and shopping basket, when describing service catalog tools — but it's the proverbial tip of the iceberg.
As with many easy-to-use service experiences … the Amazon customer doesn't see, or need to see, the activities that lie below the waterline.
But an IT organization will struggle to successfully deliver on the promise of service catalog with just the visible tip of the iceberg. There is so much more to consider — especially as many of the espoused benefits of service catalog come from the activities or capabilities that lie below the water line.
More barriers: so what went wrong (and can still go wrong)?
Many things seem obvious with the benefit of hindsight — it's definitely a true statement with service catalog. We should have known and pre-empted the following four issues (in addition to dealing with the terminology issue):
- The "let's buy a service catalog tool" approach (which is not dissimilar to the "let's buy an ITSM tool approach"). This is where the service catalog is seen as a technology project rather than a business-driven change, or it may just be seen as a "good thing to do."
- That the service catalog (management) initiative objectives can be limited or misjudged. To receive the commonly-touted benefits, a service catalog needs to be more than just a list of IT services (although for some organizations it could be all they want and need, and maybe Microsoft Excel would suffice).
- There is little or no understanding of the IT services that should populate the service catalog. It's understandable as service definition is difficult, but it's not an excuse. Any provider of services should know what they provide, from a customer perspective, and the associated attributes.
- The service catalog is created in the image of the IT organization, possibly in its ivory tower, and then pushed out to the business with great internal applause but followed by little or no business adoption. The Field of Dreams "Build it and they will come approach."
So what business issue or opportunity is your service catalog trying to help with? Is it just the latest must-have shiny ITSM tool for IT?
And will customers actively use it? Will they need encouragement? Or will they DEMAND it?
And finally … the C-word …
That C-word is "culture."
Many organizations have taken a "build it and they will come" or a "build it and they will use it" approach to service catalog. But even when more attention is paid to the ultimate use of a service catalog it can be difficult.
For instance, about a month ago I spent some time with a group of Legal Sector IT professionals here in the UK. They need to deliver efficiencies and improve service, but have challenges in service catalog adoption. And history, tradition, and norms (culture) are preventing adoption — in particular a senior-level reticence to personally change (and therefore lead by example), and the existing luxury of a very personal, maybe even concierge-like, service from IT.
Comments and questions ranged from: "How do we move from a people-intensive concierge service to self-service?" through "We have self-service but adoption is low" to "Is our 30-35% self-service adoption good?".
Legal firms also present an extra technical need for self-service — that of "delegated access" where a secretary or personal assistant, say, might log requests or incidents on behalf of a partner. Again reinforcing the need to understand business operations and norms.
So can the promised benefits of service catalog be achieved through just buying and populating a service catalog tool alone? Probably not, but people still try.
And what can you do to help ensure that your organization's service catalog initiative doesn't die a slow and painful death at the hands of misguided IT project people and unreceptive customers?
My next blog will talk to service catalog good or best practices.
1 Comment
